SUPLEMENTO MENSUAL DEDICADO A LA IMAGEN SINTETICA 



RENDERMANIA 



La Portada 



Escaramuzas 
virtuales 



Biblioteca 3D 



• Caballeros 

y zombis para 
Imagine y POV 

• 3dto3d, 

un conversor 
para Imagine 



laller Virtual 
Books.inc, 
un nuevo Ipas 
para POV 



pG<EDan/& 




'.•V 






Hb Taller Virtual 






Todo los ficheros de inclusion y los 
ejemplos podeis encontrarlos en 
el directorio 
PCMANIA\RENDER59 

del CD-Rom. 



1*1* 



Jose Manuel Munoz 



Books.inc: Un Ipas para 




La afirmacion de que las nuevas sentencias de programacion de POV son la 

novedad mas importante de la version 3 de este raytracer puede parecer 

excesiva, pero dicha afirmacion esta siendo confirmada por las nuevas 

utilidades que estan apareciendo. En el numero anterior nos asombramos 

con «Trees» de Sonya Roberts y hoy volveremos a hacerlo con «Books», 

un "Ipas" de la misma autora para crearfilas de libros virtuales. 
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crear librerias con POV 



emos decidido de- 

Mnominar "Ipas" a las 
nuevas utilidades de 
POV escritas con el 
lenguaje escenico 
de este Ray tracer, 
ya que casi todo el mundo sabe lo que es 
un Ipas (un modulo de software externo 
que es llamado por 3D Studio cuando es 
necesario y que se apoya en las propias 
funciones del programa). Los Ipas de 
3D Studio emplean una interfaz de co- 
municacion con 3D Studio para acceder 
a las funciones del programa. Esta inter- 
faz viene a ser una "puerta abierta" me- 
diante la cual los programadores pueden 
ampliar las posibilidades del programa 
en sentidos muy diversos. 

Quien conozca el mundillo de 3D 
Studio sabra que se han escrito Ipas para 
casi cualquier cosa. Pues bien; esto mis- 
mo es lo que esta empezando a suceder 
en el universo POV, con la diferencia de 
que la creation de Ipas para POV es una 
tarea mucho mas sencilla que la equiva- 
lente para 3D Studio: cualquier usuario 
de POV con nociones de programacion 
puede disenar su propio Ipas. Asf, pode- 
mos escribir Ipas para crear arboles. 
campos de meteoritos, edificios, etc. 

Seguidamente estudiaremos books.inc. 
Este Ipas, que genera filas o pilas de li- 
bros, puede no ser tan util o espectacu- 
lar como otro capaz de generar arboles. 
pero es un ejemplo perfecto de lo que 
puede conseguirse aunando imagina- 
tion con habilidad de programacion. El 
fichero es. ademas, relativamente sen- 



cillo, y podra ser comprendido incluso 
por aquellos povmaniacos que sientan es- 
calofrfos ante la palabra "matematicas". 

Filas de libros 

Books.inc permite al usuario gene- 
rar filas de libros que pueden ser em- 
pleados para dar un acabado mas com- 
pleto a cualquier escena interiorista. 
Podremos pues emplear este Ipas para 
llenar estanterias con libros o para crear 
pilas de volumenes sobre las tipicas 
mesas de trabajo. Los libros que genera 
Books no tienen un nivel de detalle 
demasiado alto, pero, a pesar de esto, las 
escenas quedaran resultonas, ya que los 
volumenes podran tener distintos groso- 
res, colores y tamanos, y podremos va- 
riar su alineacion dentro de las filas. 
Ademas, de manera similar, podremos 
hacer que las pilas de libros tengan un 
aspecto desorganizado, acorde con el 
que puede verse en las pilas de libros del 
universo real (esto 
parece ser una pre- 
ocupacion cons- 
tante en el trabajo 
de Sonya Roberts). 

Como sucedfa 
en Trees, el usua- 
rio control ara el 
funcionamiento de 
Books mediante 
una serie de varia- 
bles cuyo valor se 
introducira desde 
el fichero escenico, 
antes de colocar el Mayor variacion en 



correspondiente include. El numero de 
estas variables es bastante grande pero. 
por fortuna, no es preciso que las refe- 
renciemos todas. De hecho Sonya ha da- 
do valores por defecto a cada una de es- 
tas variables empleando la sentencia 
ifndef. Veamos un ejemplo: 
#ifndef (RowLenght) #dedare RowLength=2 #end 
En esta linea, situada al principio del 
archivo books.inc, se estipula que si la 
variable RowLenght no ha sido iniciali- 
zada antes (desde el fichero escenico del 
usuario), esta pasara a tener un valor de 
2. Este sistema es muy comodo para el 
usuario ya que se ahorrara la introduc- 
tion de valores cada vez que books.inc 
sea referenciado: si el usuario da un nue- 
vo valor a una variable, este valor susti- 
tuira al que se haya asignado por defecto 
en el ifndef. Ademas, el nuevo valor podra 
ser alterado mas adelante en una nueva in- 
vocation a books.inc. De lo contrario que- 
dara como nuevo valor por defecto. 




la colocacion de la fila. 
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Variables de control 

Ahora examinemos las variables de 
control. En primer lugar tenemos a 
"Rowlenght", que es la longitud de la 
fila o columna de libros a crear. La al- 
tura de la fila se controla con "Row- 
Height" y la profundidad de la misma 
se indica con "RowDepth". "StackSty- 
le" indica al Ipas la forma en que van a 
colocarse los libros. Si el valor es (el 
dado por defecto) los libros se dispon- 
dran de la manera corriente que pode- 
mos observar en cualquier estanterfa. 



la pila, esta se dispondra de una manera 
bastante ordenada, ya que Books "so- 
lo" aplicara un desorden maximo de 20 
grados (utilizando valores aleatorios) en 
el eje Y; de esta manera se evitara el que 
los libros esten excesivamente ordena- 
dos sobre la mesa, lo que resultaria irreal. 
Finalmente podemos dar a "StackSty- 
le" el valor 2, con el cual se generara 
otra pila como la anterior, pero mucho 
mas desordenada, ya que ahora el ran- 
go de giro de los libros oscila entre los 
y los 360 grados en el eje Y. 




Puesto que Books asume -al igual que 
la mayoria de los usuarios de POV- 
que el piano del suelo es el formado 
por los ejes X-Y, los libros se dispon- 
dran "de pie" formando una fila a lo 
largo de este piano. Los libros descan- 
saran sobre Y=0 y sus lomos estaran 
orientados en la direction -Z. La fila, 
que arranca en X=0, se extendera hasta 
el punto indicado por "RowLenght". 

Otra posibilidad es dar a "StackStyle" 
el valor 1 . En este caso los libros forma- 
ran una pila como la que puede verse en 
ciertas mesas, donde el volumen que re- 
posa directamente sobre la mesa tiene 
encima una docena o mas de tomos. La 
pila sera colocada en la position <0,0,0> 
y su altura dependera del valor dado a 
"RowLenght". En cuanto a la forma de 



Veamos ahora otras variables. "Num- 
Books" controla el numero total de li- 
bros de la fila o pila. En realidad este 
numero es aproximado ya que puede 
ocurrir que, a consecuencia de las va- 
riables que controlan las diferencias en 
el grosor de los libros, haya libros de 
mas o de menos. En cualquier caso el 
grosor medio de los libros se calculara 
dividiendo la longitud dada a la fila en 
' 'RowLenghf ' por el valor de ' 'NumBooks' '. 
Hay que tener cuidado con los valores 
dados a estas variables u obtendremos 
unos libros ridiculamente gruesos o 
muy finos, y lo mismo se aplica a las 
variables que controlan la altura de los 
tomos ("RowHeight") o el largo de los 
mismos ("RowDepth"). Estas propor- 
ciones no son difi'ciles de calcular pero 



mas vale recordar que los valores de to- 
das estas variables se combinan para 
componer los resultados. 

Sigamos con otros detalles. Si todos 
los libros generados fuesen excesiva- 
mente similares en sus dimensiones, el 
resultado seria poco atractivo. Lo que 
queremos es una libreria con tomos de 
diferentes tamanos, como sucede en la 
vida real. Esto se consigue con las va- 
riables "VariThick", "VariHeight" y 
"VariDepth", las cuales controlan res- 
pectivamente las variaciones en el gro- 
sor, la altura y el largo de los libros (con 
respecto a las dimensiones medias, por 
supuesto). Los valores dados seran de- 
cimales y es conveniente que no sean 
demasiado grandes (observe el lector el 
resultado de los valores por defecto). 

Otra variable importante de este mis- 
mo tipo es "VariAlign". Esta se emplea 
para conseguir leves diferencias en la 
alineacion de las filas de libros. El va- 
lor 0. 1 , asignado por defecto, nos dara 
filas muy ordenadas y valores mayores 
produciran filas mas desordenadas. 

De igual manera podemos conseguir 
mas diferencias entre los libros ponien- 
do a "True" la variable "VariColours". 
Con ello se asignaran colores aleatorios 
a las cubiertas de los tomos. Si, por el 
contrario, dejamos esta variable a "fal- 
se", los colores asignados se elegiran 
entre una gama de grises (el modo de 
color es el elegido por defecto). Aqui 
hay que decir que "true" y "false" son 
identificadores de POV. Un valor "true" 
es -como en el lenguaje C- cualquier 
valor distinto de 0, mientras que "false" 
es 0. Por alguna razon Sonya empleo 
"True" en vez de "true", con el resulta- 
do de que el parser de POV declara 
errores en algunos sitios. El autor de 
este articulo remedio esto anadiendo 
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#declare True=true, al principio de bo- 
oks.inc (y haciendo lo mismo con fal- 
se). ^,Un error de ultima hora? 

Por otro lado, existe una variable 
"semilla", llamada "BookSeed", que se 
emplea para inicializar el generador de 
numeros aleatorios. Con ello podremos 
conseguir filas o pilas de libros diferen- 
tes, cambiando el valor de dicha semilla 
(si estamos generando una animation 
mantendremos el mismo valor de semi- 
lla en todos los frames para obtener 
siempre la misma fila en cada uno). 

En cuanto a "FillerColour", controla 
el aspecto del canal del libro. Si el valor 
de esta variable es obtendremos un 
bianco piano mientras que un valor de 
1 proporcionara tonos grises. 

Los objetos "TEXT" 

Ya solo queda por explicar lo que ha- 
ce la variable "Titles". Si su valor es 0, 
las cubiertas de los libros seran planas. 
Si el valor es 1, habra titulos en ingles 
en los lomos de los libros. Realmente el 
pov-usuario no necesita saber mas para 
emplear Books, pero surgen varios inte- 
rrogantes: ^,C6mo se colocan las letras 
sobre los libros? ^Podemos poner nues- 
tros propios titulos? 

Veamos: las letras se colocan em- 
pleando los objetos Text implementa- 
dos en POV a partir de la version 3.0 A 
Antes de esta novedad el usuario estaba 
obligado a hacer operaciones CSG o a 
utilizar Heightfields para crear textos. 
Ahora, sin embargo, podemos emplear 
esta nueva primitiva para crear objetos- 
texto a partir de fuentes TrueType. El 
formato de la nueva sentencia es: 

text { ttf "Nombre del fuente" "cadena a 
imprimir" Profundidad, Separation ) 

En "Nombre del fuente" podemos es- 
pecificar alguno de los fuentes ttf que se 

W i 




han incluido como ejemplo en POV (o 
cualquier otro de que dispongamos). En 
cuanto a la cadena, normalmente usare- 
mos un string entrecomillado. Tambien 
resulta posible emplear una variable de 
cadena, en cuyo caso bastara con incluir 
el nombre de la misma, sin las comillas. 
Los parametros siguientes determinan la 
profundidad de la letra y el espacio de 
separacion. Por defecto las letras se co- 
locan sobre el piano X-Y,pudiendose le- 
er el texto desde -Z. La parte frontal del 
texto queda en Z=0. 1 y cada letra tiene 
de 0.5 a 0.75 unidades de altura. Asf 



Diferentes pruebas. Notese como 
el titulo puede acabar fuera del 
libro por excesiva longitud o por 
poco grosor del libro. 



pues, "Profundidad" se refiere a las di- 
mensiones del objeto a lo largo del eje 
Z. En cuanto al siguiente parametro 
hay que tener cuidado, ya que si no in- 
dicamos un eje, el valor de separacion 
se aplicara como una suma en los tres 
ejes (cada letra se alejara de la anterior 
en cada eje). Esto se evita escribiendo 
cosas como ".3*x", lo cual restringe 
cada desplazamiento al eje indicado. 

Cadenas 

En books los titulos se componen 
aleatoriamente defmiendo un string a 
partir de la suma de otros tres. La va- 
riable string obtenida, "BookTitle", se- 
ra luego empleada para los objetos ttx. 
Esta suma se lleva a cabo empleando 
una de las nuevas sentencias de trabajo 
con strings de la forma: 
#declare BookTitle=concat(First, Second, 
Third) 

La funcion concat realiza la suma de 
las cadenas contenidas en las variables. 
Si por ejemplo, sus valores respectivos 
eran "The ", "Lost " y "World", el resul- 
tado sera "The Lost World". Las pala- 
bras para cada una de las tres variables- 
sumando se extraen aleatoriamente 
(empleando rand y switch) de tres listas 
que podemos hallar en titles.inc. (este 
metodo es similar al que se usaba en 
broma para hacer que los programas 
creasen poemas). Sin embargo, y por 
aquello de crear titulos en castellano, ne- 
mos creado un fichero aparte donde las 
cadenas son titulos completos y no se 
emplea rand (confiemos en que Sonya 
no se moleste por ello). Hemos incluido 
ejemplos de uso. Solo queda advertir 
que tengais cuidado al poner vuestros ti- 
tulos, ya que podeis exceder el espacio 
para ponerlos (esto puede arreglarse 
cambiando el scale del objeto text). 
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Modelos para una batalla 

Durante meses los rendermaniacos han enviado material belico para 
participar en la batalla entre Orcos y Humanos que estaba prevista para 
este mes. Catapultas, canones, transportes, e incluso un 
par de guerreros y un mago han llegado a Rendermania 
para apoyar a uno u otro bando. Y este mes (jpor fin!) ha 
llegado la hora del encontronazo virtual. Sin embargo, la 
horda orca no se ha presentado. En su lugar ha acudido 
al campo de batalla una horda de no-muertos. 



nte todo, quisiera- 

Amos disculparnos 
por haber sustituido 
a la horda orca por 
los zombis que po- 
deis ver en estas pa- 
ginas. Esto ha sido debido a una imper- 
donable falta de prevision. En el 
numero anterior nos parecio que ya ha- 
bi'a material suficiente para preparer 
una buena batallita virtual, pero faltaba 
lo mas importante: ;los Orcos! 

Por que no hay orcos 

Lo cierto es que, como recordaran 
los lectores, disponfamos de un orco 
que habfa sido cedido amablemente por 
Jose Gonzalez Iniesta. Este orco era un 
magnifico representante de la raza ver- 
de: tenia grandes colmillos, unos hom- 
bros de metro y medio de ancho, una 
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apanencia 
que inspiraba 
terror al enemigo y. como no, despren- 
dfa un hedor capaz de poner en fuga a 
cualquier humano. Sin embargo, al fi- 
nal no pudo ser utilizado. ^Por que? 
Pues porque el orco no habi'a sido dise- 
nado expresamente para una batallita 
virtual como la que se pretendfa prepa- 
rer. No estaba articulado y unicamente 
poseia una texture para la parte frontal. 
Como el modelo no estaba dividido 
en dos partes, la textura -creada para 
representar la parte delantera del orco- 
quedaba aplicada tambien en la parte 













de fantasia medieval 



posterior de la criatura verde, con lo 
cual no resultaba conveniente que el 
modelo quedara de espaldas a la cama- 
ra (jentonces se apreciaba que no habfa 
espaldas, sino dos lados delanteros!). 
Asi', el orco solamente podia ser visto 
de frente (bastaba con hacerlo girar 
unos pocos grados para advertir que es- 
taba incompleto). Quiza se pudo haber 
creado una escena donde los orcos solo 
presentasen la parte frontal a la camara, 
pero esto hubiese recortado seriamente 
las posibilidades en el diseno de la por- 
tada. Ademas, los guerreros humanos 
estaban articulados y podia prepararse 
cualquier numero de posturas para 
ellos; por tanto resultaba deseable ha- 
cer lo propio con los orcos. 

De esta manera se llego a la conclu- 
sion de que se necesitaba un orco tan 
manejable como el lancero humano. 
Fue entonces cuando, sabiendo que Jo- 
se Gonzalez tenia en ese momento tra- 
bajo suficiente como para ahogarse en 
el, decidimos hacer nosotros mismos 
al orco. 

Para ello disponfa de la magnffica 
documentation que supone la revista 
White Dwarf, donde hay docenas de 
fotografias de miniaturas de orcos. 
Pronto, no obstante, hubo que rendirse 
a la evidencia: preparar un orco mfni- 
mamente aceptable no es algo que se 
haga en unas pocas horas. Quien haya 
visto alguna de las muchas ilustracio- 
nes que existen sobre esta raza fantasti- 
ca sabra que los orcos no suelen llevar 
armaduras. La mayor parte de su cuer- 
po -parecido al humano pero mucho 



mas fornido- queda al descubierto. Era 
pues preciso crear un cuerpo antropo- 
morfico que exhibiera lo mas fielmente 
posible la brutal musculature orca. Ha- 
cer esto desde cero ya suponfa una ta- 
rea muy diffcil pero, ademas, tambien 
era preciso crear un rostro que pudiese 
variar de expresion y que fuese facil- 
mente deformable, lo cual era -como 
ya imaginara el lector- una empresa 
aun mas laboriosa. Resumiendo, las al- 
ternativas posibles eran: 

1 ) Crearlo todo (cuerpo y cabeza) 
partiendo de cero. 

2) Realizar deformaciones de una 
malla freeware de un cuerpo humano 
hasta obtener el orco. 

3) Utilizar bitmaps para represen- 
tar detalles inexistente en un modelo 
3D basicamente muy sencillo (como es 



el caso de los modelos de «Quake» o 
del propio orco de Jose Gonzalez). 

4) Crear un modelo muy simple 
que solamente fuese visto a distancia. 

5) Hacer otra cosa. 

6) Renunciar a la batallita. 

Las dos primeras opciones se pusie- 
ron en practica hasta que resulto evi- 
dente que los progresos eran demasia- 
do lentos. jSencillamente no habfa 
tiempo de hacer un orco decente en los 
dias disponibles! En cuanto a la tercera 
opcion, nuestra habilidad como grafis- 
tas 2D no estaba a la altura de las cir- 
cunstancias. La siguiente opcion, la 
cuarta, fue rechazada sin mas. puesto 
que se deseaba un orco del que sus co- 
legas verdes no se avergonzaran. Asi 
pues, solo quedaban dos opciones: o 
bien renunciar al encuentro o bien "ha- 
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cer otra cosa". Por supuesto tambien se 
hubiera podido aplazar el encuentro pe- 
ro esto hubiera sido defraudar a todos 
aquellos que deseaban participar en el. 
La batalla, pues, debia celebrarse a to- 
da costa, aunque faltaba uno de los 
bandos... 

La noche de los muertos 
vivientes 

Afortunadamente somos autenticos 
devoradores de literatura fantastico-he- 
roica y por esta razon no tuvimos que 
estrujarnos los sesos hasta niveles criti- 
cos para hallar una solucion. Los adep- 
tos al genero, quienes hayan leido a 
Howard, Zelazny, Leiber, Moorcok, 
Tolkien y a tantos otros, se habran dado 
cuenta de que tarde o temprano en estas 
historias siempre aparece una legion de 
muertos vivientes (de hecho, en «War- 
hammer» tambien figura un ejercito de 
no muertos). Esta fue la solucion adop- 
tada por razones obvias. En primer lu- 
gar disenar un zombi es muy facil, uni- 
camente hay que hacerse con algiin 



modelo de esqueleto y modificarlo para 
nuestros fines. Ademas el no-muerto, 
al consistir solamente en huesos, no 
presenta las complicaciones de mode- 
lado tfpicas de las caras o de los mus- 
culos y resulta muy facil articularlo (to- 
do el mundo sabe donde estan los ejes 
de giro de un cuerpo humano). 

Una vez tomada esta resolution el 
siguiente paso a tomar fue considerar 
donde iba a tratarse el modelo. O sea, 
donde iban a crearse las diferentes pos- 
turas que, mas tar- 
de, en «POV», se 
emplearfan para 
generar las esce- 
nas. Esta decision 
no fue dificil. 

«Imagine» dis- 
pone de un exce- 
lente modelador 
que resultaba ade- 
cuado para crear 
los pocos objetos 
necesarios. Permi- 
te una facil modi- 



fication de los modelos utilizando ope- 
raciones que pueden afectar a objetos, 
caras o puntos y, sobre todo, es ideal 
para establecer jerarqufas de objetos, lo 
cual es indispensable para preparar 
posturas. 

El guerrero humano 

Una vez decidido el uso de «Imagine» 
se opto por preparar al guerrero huma- 
no en primer lugar. Este era el modelo 
que iba a representar al bando humano. 
Fue creado en «3D Studio» y era dese- 
able comprobar si iban a presentarse 
problemas de traduction de formatos 
antes de empezar con el esqueleto (que 
tambien es un modelo de «3D Stu- 
dio*). Efectivamente hubo problemas. 

Para empezar se supom'a que tanto 
«Imagine» como «3D Studio» pueden 
leer ficheros dxf. Pues bien, mientras 
que «3D Studio* no presento proble- 
mas para leer los dxf grabados desde 
«Imagine», este ultimo si los dio para 
leer los dxf grabados desde «3D Stu- 
dio*. «Imagine» se ponfa a leer y a leer 
para, finalmente, mostrar un eje solita- 
rio en pantalla, pero del objeto leido, ni 
rastro. Por supuesto, uno siempre tiene 
que dejar una puerta abierta a la admi- 




sion de haber cometido un 

error o alguna omision ca- 

tastrofica, pero en este ca- 

so, al no haber encontra- 

do opciones de lectura, 

simplemente se acepto 

que esta opcion no fun- 

cionaba (probablemente lo 

hara con archivos dxf mas 

antiguos que los que graba 

«3D Studio»). Entonces se 

empleo el conversor Wcvt2pov, ya pu- 

blicado hace tiempo en PCmanfa. 

Wcvt2pov no realiza traducciones di- 

rectas al formato de «Imagine» pero 

permite leer ficheros 3ds y grabar dxf. 

Despues de las primeras pruebas se 

comprobaron dos cosas: 

A) «Imagine» leia los dxf grabados 
por Wcvt2pov (aunque tardaba un 
tiempo considerable en leer los mas 
largos) pero convertia los modelos lei- 
dos en un unico objeto. 

B) En caso de que se grabase pieza 
a pieza como dxf un modelo desde 
Wcvt2pov, «Imagine» daba a los obje- 
tos lei'dos tamafios que no correspondi'an 
a sus dimensiones originates. Las pie- 
zas, por tanto ya no encajaban entre si y 
se hacia preciso reescalarlas y posicio- 
narlas nuevamente desde «Imagine». 

Asi pues, al no encontrar un conver- 
sor directo 3ds-obj, fuimos importan- 
do pieza a pieza desde «Imagine». Para 
reescalar y situar las piezas se importo 
tambien un modelo completo del lan- 
cero que sirvio de pista para compro- 
bar las dimensiones y la position de ca- 
da objeto. Despues de un trabajo 
mecanico y aburrido, el lancero quedo 
listo. Fue entonces y solo entonces 
cuando, examinando las cartas del foro 




del lector encontramos la referenda a 
3dto3d en la carta de Victor Tovio 
Ciercoles. (Nota del autor: estamos se- 
guros de haber oido antes referencias a 
3dto3d pero las habiamos olvidado to- 
talmente. Gracias, amigo Victor). 

3dto3d 

3dto3d es un conversor de formatos 
3d. Permite una perfecta comunicacion 
entre «POV», «3D Studio» e «Imagi- 
ne», aunque no pueden pasarse escenas 
de «POV» a «3D Studio» ni a «Imagi- 
ne». Las traducciones realizadas con 



3dto3d presentan algunos 
problemillas menores pe- 
ro la alternativa -como 
habreis comprobado por 
los parrafos anteriores- 
es mucho peor. 
La version que este mes 
publicamos es la remitida 
por Victor. Esta version 
ya habia sido publicada 
antes en la revista, pero 
no lo recordamos a tiempo. La version 
funciona bajo MS-DOS por el sistema 
de la lfnea de comandos. El formato de 
uso de la utilidad es: 

3dto3d fichero.ext /opcion /opcion 

Hemos de indicar a 3dto3d el forma- 
to del fichero a traducir con la opcion 
"i". A este caracter seguira un valor in- 
dicando el formato del fichero de en- 
trada. Un valor de (el asignado por 
defecto) corresponde al formato Raw. 
El valor 1 es el de los ficheros 3ds («3D 
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Studio»), el 2 el de los archivos .obj 
(«Imagine») y el 3 el de los ficheros 
Lwo («Lightwave»). Para especificar el 
formato del fichero de salida usaremos 
la option "o" seguida de un valor nu- 
merico. Este valor sera de para los fi- 
cheros raw puros (sin almacenar los 
vectores de las normales), de 1 para los 
raw suavizados (en los que sf se alma- 
cenan estas normales), y de 2 para 
«POV». Merece la pena indicar que la 
option 2 graba tambien un fichero en 
formato Udo que -segiin parece- pue- 
de ser leido por «Moray». 

Otros valores validos para "o" son el 
3 («Polyray»), el 4 (Asc, el formato as- 
cii de «3D Studio*), el 5 (Obt), el 6 
(Rpl de «Real 3D»), el 7 (3ds), el 10 
(obj de «Imagine»), el 11 (Rwx de 
«Renderware»), el 12 (Wrl de «Vrml 
1 .0») y el 13 (Dxf)- Los valores 8 y 9 se 
emplean respectivamente para generar 
objetos wireframe y blob para «POV», 
pero no han sido probados aiin. 

Asf pues, por ejemplo, la lfnea... 

3dto3d nombre.3ds /il /olO 

...generana un fichero obj para 
«Imagine» a partir del fichero de «3D 
Studio» dado como entrada. Esta con- 
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version no parece presentar problemas 
pero lo contrario si puede ocasionar al- 
gunos contratiempos. A veces. los mo- 
delos obj exportados al formato de «3D 
Studio» no se visualizan correctamente 
desde «3D Studio» y puede suceder 
que la mitad de los poh'gonos no sean 
visibles. Si queremos solucionar esto 
desde el mismo «3D Studio» bastard 
con unificar las normales del objeto. 
;Los poh'gonos estan ahi! unicamente 
ocurre que el lado visible de las caras 
(indicado por la normal de cada polf- 
gono) apunta en direction opuesta a la 
visible. Tambien podemos afiadir la op- 
tion /u a la lfnea de ordenes de 3dto3d. 
Esta orden -segiin el manual- unifica 
las normales del objeto, pero aparente- 
mente no funciona. Tambien puede su- 
ceder que el modelo se vea facetado 
desde «3D Studio» aunque original- 
mente su superficie estuviese suaviza- 
da. Para remediar esto desde «3D 
Studio» 



bastara con aplicar un comando de sua- 
vizado (nota: 3dto3d tambien ofrece el 
comando /s para hacer esto pero, nue- 
vamente, parece no tener efecto). 

Por el contrario la conversion 3ds - 
obj no dio problemas en ninguna de las 
pruebas realizadas y fue asi como el 
modelo del esqueleto se paso a «Imagi- 
ne». Despues de la conversion, los ob- 
jetos componente del modelo siguen 
siendo independientes en «lmagine». 
No se fusionan en un unico objeto. To- 
dos los objetos individuates se ataran a 
uno de mayor jerarquia (que, es de su- 
poner, 3dto3d elegira "a dedo"), y todo 
el modelo podra ser referenciado pin- 
chando sobre este objeto "padre". Una 
vez que tenemos el modelo en la panta- 
11a de «Imagine» podremos desagrupar- 
lo y establecer las jerarqufas necesarias 
antes de grabarlo. 

Preparation de los 
luchadores 

Una vez cargados los dos modelos 
en el Editor de Detalles de «Imagine», 
se crearon las relaciones jerarquicas 
para poder preparar las posturas nece- 
sarias para 
la batalla. 
Antes, 




embargo, se estudio el tamano relativo 
entre ambos modelos y se realizaron al- 
gunos ajustes de poca importancia en 
los dos. Quiza el mas importante sea el 
realizado en las manos. Aunque crear 
posturas nuevas de modelos como es- 
tos puede ser bastante divertido, colo- 
car la posicion de las manos es siem- 
pre una tarea molesta. Simplemente 
hay demasiados objetos y puntos de gi- 
ro. El usuario pierde siempre un buen 
rato colocando la posicion de cada de- 
do y a menudo se encuentra con que la 
disposicion obtenida no resulta ade- 
cuada y hay que volver a empezar. 

Para estos personajes se decidio su- 
primir el problema de rai'z. En los dos, 
las manos estan cerradas, como asien- 
do algo, y forman un unico objeto ata- 
do a la mufieca. La idea surgio ojeando 
una White Dwarf. Al contemplar las 
fotograffas, observamos que practica- 
mente todas las miniaturas tem'an las 
manos cerradas en un puno, lo cual era 
lo mas natural del mundo ya que siem- 
pre asi'an algo: un escudo, una espada, 
una lanza... Incluso en los raros casos 
en que una mano quedaba libre, esta 
formaba un puno. Esto deja abierta la 
posibilidad de que el personaje agarre 
el mismo arma con las dos manos (co- 
mo se ha hecho en un par de posturas 
del zombi) o de que se pueda colocal 
otro arma facilmente. Una vez decidido 
esto se preparo la postura para la mano 
esqueletica y se unio (join) en un unico 
objeto. La mano del humano fue algo 
mas complicada ya que la que se pre- 
paro originalmente fue sustituida por 
otra recortada de la malla de un modelo 
humano (borrando el resto de los pun- 
tos del modelo). 

Despues se fijaron las proporciones 

de ambos modelos. Se deseaba que el 

I I 




humano fuera bastante mas bajito, asi 
que el zombi le saca mas de una cabe- 
za. Tambien se aumento bastante el ta- 
mano de la cabeza y de las manos ori- 
ginales del esqueleto -a fin de que no 
resultase un modelo demasiado serio- 
y finalmente se le anadieron unos ojos 
Nota: parece increfble como puede 
cambiar un esqueleto al ponerle ojos. 
Con las cuencas oculares vacfas, el mo- 
delo da miedo mientras que con los 
ojos, el modelo pierde bastante horror 
y puede, en algunas posturas, hasta dar 
risa. Este efecto de caricatura puede au- 



nar las proporciones finales de los dos 
guerreros y sus armas. Originalmente 
el humano era un lancero y de hecho se 
preparo una lanza para el, pero final- 
mente no se preparo ninguna postura 
con ella. En lugar de esto se decidio 
preparar una espada de aspecto bastan- 
te bestial y un escudo. Esto se hizo en 
parte para dar un aspecto mas combati- 
vo al personaje y en parte porque resul- 
taba mucho mas sencillo preparar pos- 
turas para el poniendole un objeto en 
cada mano que haciendole asir una lan- 
za con las dos manos (probadlo y ve- 




mentar si quitamos algunos huesos y 
damos mayor tamano a algunas articu- 
laciones como la cabeza, los pies, las 
manos, etc. En nuestro caso, estos cam- 
bios solo fueron moderados. 

Armas para la contienda 

El siguiente paso fue preparar las ar- 
mas para ambos contendientes. En el 
fichero base.obj, el lector podra exami- 



reis). El diseno de estas armas no pre- 
sentara ningiin misterio para los 
lectores que hayan lei'do las notas que 
hemos ido publicando sobre «Imagi- 
ne». El escudo son dos discos extrui- 
dos, uno de los cuales fue recortado. La 
hoja de la lanza se creo dibujando una 
forma bidimensional que fue extruida. 
editandose despues sus puntos. Por ul- 
timo, la hoja de la espada se creo edi- 
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tando los puntos de un piano 
extruido (con practica este 
metodo es mas rapido de lo 
que parece a primera vista). 

Una vez creadas las ar- 
mas, estas fueron traslada- 
das y rotadas hasta colocar- 
las en los pufios de nuestros 
audaces contendientes, des- 
pues de lo cual fueron "ata- 
das" a los objetos-mano co- 
mo objetos-hijos. 



La conversion a POV 

Como los modelos iban a ser rende- 
rizados desde «POV», era preciso que 
estos se almacenaran en una posicion y 
escala que facilitara' su manejo desde 
este programa. Como ocurria con «3D 
Studio» y «POV», «Imagine» tiene los 
ejes cambiados con respecto a nuestro 
trazador favorito, y fue preciso realizar 
unas cuantas operaciones sencillas para 
no hacer posteriores ajustes desde 
«POV». Hecho esto los modelos, una 
vez importados por «POV», quedaron 
con los pies sobre el suelo formado por 
el piano X-Z, a la altura Y=0. La cara 
de los modelos quedo mirando parale- 
lamente al eje Z, en direction al lado 
negativo del eje. Veamos como conse- 
guir esto. Hay que seguir estos pasos: 

1) Hay que rotar el modelo hasta 
que este quede como puede verse en la 
foto: de pie y mirando hacia el especta- 
dor en la ventana Top, de modo que pa- 
rezca visto desde arriba -y con los pies 
apuntando hacia el marco inferior de la 
ventana- desde arriba en la ventana 
Front. Tambien debera quedar extendi- 
do horizontalmente, con la cabeza ha- 
cia el lado derecho y mirando hacia 
abajo, en la ventana Right. 




2) Despues hay que situar los pies 
del personaje sobre el que sera el suelo 
en «POV». Para ello iremos al menu 
"Display" y pulsaremos sobre la op- 
tion "Coordinates". Entonces aparece- 
ran sobre la fila superior tres valores 
numericos que iran variando conforme 
desplacemos el cursor. Estos valores 
correspondent a la posiciones X,Y,Z 
sobre las que vaya pasando el cursor, 
al desplazarse por las ventanas de tra- 
bajo. Elegiremos una vista, colocare- 
mos el cursor en la mismfsima suela 
del zapato del personaje y tomaremos 
nota del valor devuelto en el eje Y (el 
valor del centro). Hecho esto solo nos 
restara efectuar una traslaci6n del mo- 
delo. Podemos hacerla manualmente 
pero resulta mas preciso recurrir a la 
ventana de transformaciones (Alt-T). 
Escribiremos en la columna del eje Y 
el valor lefdo antes, pero dandole el 
signo opuesto (y no olvideis el Re- 
turn). Ademas deberemos pulsar sobre 
el flag de "World" antes de pinchar so- 
bre "Perform". 

3) Finalmente escogeremos un 
punto del personaje como centro en el 
piano X-Z. Lo ideal es hacer esto des- 
de la ventana donde vemos al persona- 
je desde arriba. Como antes, tomare- 
mos nota de los valores devueltos por 
el cursor para este punto central (pero 



ahora para X y Z). Luego in- 
vocaremos nuevamente al 
gestor de transformaciones 
para el modelo y daremos los 
valores lefdos (que son, claro 
esta, la distancia a <0,0> de 
los ejes X y Z) cambiando el 
signo. Asi, despues de pin- 
char en "World" y "Perform", 
el muneco estara perfecta- 
mente centrado en la posicion 

desde la que debe ser "traducido" a 

«POV». 




Una vez obtenidas la orientaci6n y 
la posicion con que el personaje apa- 
receria en «POV» despues de la tra- 
duction, llego el momento de ponerse 
a preparar posturitas. Para nuestra ba- 
talla se necesitaban muchas posturas 
diferentes de humanos y zombis dando 
y recibiendo lena. Cada postura impli- 
caba un fichero que serfa traducido al 
formato de «POV» mas tarde. Como 
las posturas se crearon partiendo de la 
orientation y posicion ya logradas en 
el primer modelo grabado, todos los 
modelos-postura aparecieron en el uni- 
verso de «POV» con los pies sobre la 
posicion <0,0,0>. Esto ya garantizaba 
que no iba a costar mucho ir situando- 
los en el campo de batalla. Despues de 
llevar a cabo los tres pasos ya descritos 
se grabo el modelo y se realizaron en 
el los cambios necesarios para cada 
postura. Cada vez que se obtenia una 
nueva postura, se la grababa y se rese- 
teaba al Editor de Detalles para leer de 
nuevo la postura original sobre la que 
se deseaba trabajar para obtener todas 
las demas. Por supuesto, tambien se 
podia emplear alguna de las posturas 
ya obtenidas, cuando ello resultaba 
mas facil. 
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Otra vez el 3dto3d 

Supongamos que ya tenemos todos 
los ficheros-postura. Procederemos a 
convertir cada obj con una linea como... 

3dto3d postura.obj /i2 /o2 /s45 

Esto creara un fichero inc que sera 
directamente digerible por «POV». 
Hay, sin embargo, un problema. La 
conversion a «POV» crearS un declare 
para cada objeto dentro de un fichero 
.inc que puede tener varios Megas de 
tamano. No se crea, sin embargo, nin- 
gun #declare para la unidn de todos los 
objetos constituyentes del modelo. Y 
tampoco se afiaden texturas, ni pig- 
mentos, ni luces, ni camaras. (Nota: 
nosotros no nemos hallado ninguna op- 
cion de 3dto3d para ello). 

Esto derivo en una terrible pesadilla 
pues obligo a emplear un Editor de 
Textos en cada uno de los 25 archivos- 
postura para colocar manualmente las 
texturas y eliminar los declares (el lec- 




tor podra imaginarlo si tiene 
en cuenta que cada .inc 
obtenido tiene 
un tamano que 
oscila entre los 
3.5 y los 4 Me- 
gas para cada 
modelo-postura). 

Desde los ficheros escenicos de 
«POV» cada postura se trata asi: 

object {#include "posturaX.inc" rotate 
<x,y,z> translate <nx,ny,nz> } 

Naturalmente la postura podria ha- 
berse grabado como un unico objeto 
antes de realizar la traduction pero ello 
hubiera implicado que solo habrfa un 
color por postura. Finalmente hay que 
recordar que 3dto3d graba tambien un 
fichero udo por cada postura. En nues- 
tro caso este fichero no nos interesa de- 
masiado, pero puede ser conveniente 
que tomeis nota de que, al principio del 
mismo, se afiaden las dimensiones del 




modelo convertido en los distintos ejes. 
Esto puede ser muy util para estimar 
las distancias en la colocacion de los 
modelos. 

Nota: 3dto3d solamente convierte fi- 
cheros .obj de «Imagine», no objetos 
creados desde el Editor de Formas. Pa- 
ra traducir objetos creados desde este 
modulo sera preciso grabarlos desde el 
Editor de Detalles y darles la termina- 
tion .obj. 

Las postures 

Para la batalla se prepararon 25 pos- 
turas del zombi y del humano. Hay 
golpes, cai'das, cadaveres e incluso 
posturas de los personajes volando 
(tras recibir supuestamente un cafiona- 
zo). Pero lo cierto es que hubieran sido 
necesarias muchas mas para preparar 
una batallita en condiciones. Desafor- 
tunadamente cada postura, humana o 
zombi, demanda mucha memoria de 
«POV» (junos 8 Megas!). En estas cir- 
cunstancias, ^para que hacer mas? Aqui 
se echo en falta una buena utilidad de 
reduction de poh'gonos. Con ella hu- 
biera sido sencillo reducir el tamano de 
los archivos a dimensiones manejables. 

Podeis encontrar los ficheros obj con 
los modelos en el CD-ROM. 






La Portada 



Trazado de batallas 



En portada podeis 
admirar diversos 
modelos realizados 
por los lectores como 
apoyo a la idea de un 
enfrentamiento virtual 
entre humanos y orcos. 
Esta idea inicial ha 
sufrido ciertas 
modificaciones 
debidas a limitaciones 
en el tiempo y en el 
hardware disponibles. 
Seguidamente 
estudiaremos estos 
problemas teniendo 
en mente futuras 
colaboraciones de los 
rendermaniacos en 
proximas portadas. 




^^^ in duda, la portada 
del presente numero 
supondra una sor- 
presa, y probable- 
mente una decep- 
cion, para todos 
aquellos que esperasen encontrar una 
imagen repleta de orcos y humanos lu- 



chando. Las razones de la no compare- 
cencia del bando orco ya han sido ex- 
plicadas, por lo que no vamos a insistir 
en ellas. En lugar de esto explicaremos 
en detalle todos los problemas que se 
dieron en la generation de esta escena, 
a fin de prevenir su repeticion en proxi- 
mas ocasiones. 



Falta de memoria 

Las limitaciones antes mencionadas 
han determinado en gran medida las 
modificaciones hechas a la idea origi- 
nal. El problema mas grave ha sido, por 
supuesto, el de la memoria: la portada 
habfa de generarse en un PC con 64 
Megas de RAM y cada personaje, hu- 
mano o zombi, precisaba de 8. Esto ha 
limitado enormemente el numero pre- 
visto de contendientes y constituye un 
monumental fallo de planificacion por 
nuestra parte, ya que los requerimien- 
tos de memoria del guerrero humano 
eran conocidos desde hacia tiempo. 
(Nota del autor: en mi descargo debo 
anadir que, aunque conocfa el proble- 
ma podfa hacer bien poco por reme- 
diarlo puesto que no dispongo de nin- 
gun reductor de polfgonos. Ademas 
resulta bastante diffcil crear buenos 
modelos con cientos -en vez de miles- 
de caras. En estos casos suele ser preci- 
so realizar bitmaps para disimular la 
falta de detalle de estos modelos y, co- 
mo ya hemos comentado antes, no so- 
mos especialmente habiles como gra- 
fista2D). 

Los modelos de los 
rendermaniacos 

Para la portada hemos seleccionado 
las maquinas de guerra enviadas por 
Oscar Alvarez Diaz. Daniel Susfn Ace- 
bo, Julian Hierro Garcia y Carlos Vilas 
Arias. Tambien estaba previsto incluir 
el maravilloso mago de Juan Carlos Ji- 
menez Mendez. pero al final no fue in- 
cluido debido a la falta de RAM (esta- 
ba previsto darle el mando del ejercito 
zombi pero al final, en vista del escaso 
numero de no-muertos que compare- 
cieron...). Tambien hubo otros modelos 
que, por una u otra razon, no pudieron 



ser incluidos en es- 
ta lista. Entre ellos 
podemos citar a 
Roberto Reboiro 
Jato. Su catapulta 
mereci'a ser inclui- 
da aquf pero, desa- 
fortunadamente, 
Roberto solo envio 
los mdl. Nosotros 
no tem'amos insta- 
lado «Moray» y, 
debido a la falta de 
tiempo. no fue po- 
sible efectuar la 
conversion. 

Por otro lado la 
preparation de los 
modelos incluidos 
se llevo su tiempo. 
Logicamente, al 

no haberse publicado instrucciones so- 
bre este particular, cada lector envio su 
trabajo con una escala y orientacion de 
ejes distinta. Esto obligo a leer los 
fuentes y a realizar ligeros cambios pa- 
ra adaptar los modelos a la escala y 
orientacion pensados para la portada. 
Esta tarea fue bastante fastidiosa ya 
que nadie penso en poner comentarios 
en sus fuentes indicando las dimensio- 
nes de sus modelos y la altura a la que 
se habfa colocado el suelo. Ademas, 
casi ningiin lector penso en centrar los 
modelos en los ejes, lo cual hubiera fa- 
cilitado mucho la tarea de situarlos en 
la escena. 

Otro detalle fastidioso en que caye- 
ron bastantes lectores fue el de renom- 
brar las declaraciones de bastantes tex- 
turas de madera o metal. Como el 
fichero de generation de la portada in- 
clui'a varias catapultas que empleaban 
las mismas texturas de madera, esto 




ocasiono que se produjeran cambios 
en el acabado de otros modelos que 
empleaban las mismas texturas y tam- 
bien aparecieron algunos bugs que re- 
quirieron un fastidioso proceso de de- 
puration. Finalmente, algiin lector ha 
incluido modelos cuyos fuentes de- 
mandaban algun bitmap que no ha sido 
proporcionado. 

La portada final 

La idea inicial para la portada con- 
templaba el uso de las viejas librerfas 
de pueblos y castillos medievales que 
se publicaron en los primeros numeros 
del suplemento Rendermanfa. Sin em- 
bargo, habfa varios factores que desa- 
consejaban el uso de estas librerias pa- 
ra construir los fondos de la portada. El 
problema principal venia dado por los 
requerimientos de memoria. La razon 
de este excesivo gasto radica en que las 
dos librerias estan agrupadas en dos 
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grandes ficheros que em- 

plean un gran numero de 

declaraciones (para una 

proxima version esto 

cambiara y la librerfa se 

descompondra en un buen 

numero de ficheros inc 

mas pequeiios). Por otro 

lado, ademas, no deseaba- 

mos emplear nuevamente 

estas librerias en una por- 

tada en tanto no se inclu- 

yeran mejoras como nuevos edificios, 

nuevas texturas, etc. 

Entonces, despues de quemar neuro- 
nas durante algun tiempo, aparecio la 
siguiente idea: ipor que no emplear a 
los guerreros y al resto de los modelos 
como si fuesen miniaturas que estuvie- 
sen librando una batalla de juego al es- 
tilo de las de «Warhammer»? Para 
crear esta impresion unicamente era 
necesario situar los modelos sobre una 
mesa y colocar tambien los objetos tf- 
picos que pueden verse en las mesas; 
lapices, teclados de ordenador, libros, 
etc. Por supuesto de ahf a la utilization 
de los objetos-libros de Sonya Roberts 
solo habia un paso. Los libros podi'an 
ser utilizados como plataformas por las 
"miniaturas" y ademas aportaban un 
buen contraste. 

El siguiente paso, una vez colocadas 
las filas de libros, fue decidir la orienta- 
tion de la camara. Como no se deseaba 
perder mas tiempo anadiendo detalles 
adicionales como paredes, muebles, 
etc., se enfoco la camara de modo que 
las filas de libros actuasen como fondo. 
Al mismo tiempo, como se precisaba 
enfocar un buen trozo de mesa donde 
colocar las miniaturas, la camara se dis- 
puso de tal manera que pudiese captar 
tres zonas diferenciadas: la librerfa de 




fondo, las miniaturas de la mesa y las 
miniaturas que luchan en primer piano 
sobre una fila de libros. 

Indudablemente se echan a faltar 
muchos detalles en la escena: la mesa 
deberia tener una lampara y no hubie- 
ran venido mal algunos elementos mas 
(de los tipicos que pueden hallarse en 
cualquier mesa). Tambien hubiera que- 
dado bonito poner a los pies de cada 
modelo una peana, como las que suelen 
tener las miniaturas, pero no se dispo- 
nfa del tiempo suficiente para crear es- 
tos detalles. Tambien es una pena no 
haber podido meter varias parejas mas 
de combatientes pero... 

Reglas para posibles 
portadas futuras 

No renunciamos a crear una autentica 
batalla entre orcos y humanos algun dia, 
si se resuelven estos problemas. Mien- 
tras tanto confiamos en que los autores 
de los modelos empleados no se hayan 
molestado por los cambios hechos a la 
idea original (jno hubo mfe remedio!) 
Si algun dia la batalla puede celebrarse, 
estos modelos seran utilizados. 

Ahora veamos las clausulas que re- 
giran la creation de las proximas por- 
tadas hechas con ayuda de los lectores: 

1) Cada 4 meses se publicara una 



portada que incorporara 
modelos hechos por los 
lectores. El motivo de la 
portada debera cefiirse 
-aunque sea tangencial- 
mente como en el presen- 
te caso- a un tema anun- 
ciado previamente. Si la 
respuesta de los lectores 
es insuficiente, la portada 
se cancelara. 
2) Para cada portada se 
publicaran reglas especiales adiciona- 
les, segiin sea el caso. Estas reglas se re- 
feriran a las dimensiones que deberan 
tener los modelos y tambien a su orien- 
tation y al programa en que se realiza- 
ran las portadas (normalmente «POV»). 

3) Los fuentes de generation de 
los modelos enviados (en el caso de 
«POV») deberan indicar comentarios 
sobre la orientaci6n del morro del mo- 
delo y sobre sus dimensiones. Todos 
los modelos deberan estar siempre re- 
posando el piano X-Z, con los pies a la 
altura de Y=0 (y preferentemente mi- 
rando en la direction -Z). 

4) Cada metro virtual equivaldra a 
lOunidades. 

El tema elegido para la proxima por- 
tada popular sera "Mechs". Si utilizais 
«3D Studio» o «Imagine» se agradecera 
que establezcais las jerarqufas de obje- 
tos aunque, si lo preferis, podeis enviar 
las "posturas" que creais adecuadas. En 
caso de que se reciba un numero de mo- 
delos muy alto, seran empleados los que 
se consideren mejores o mas apropiados 
para el motivo de la portada. Nota: esta 
portada no tiene por que ser una escena 
de guerra. Tambien podeis enviar suge- 
rencias acerca de como imaginais voso- 
tros la portada o de como preferis que 
se empleen vuestros modelos en ella. 
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Nota importante. Podeis remitirnos vuestros trabajos o consultas, bien por carta a la direction que 
figura en la segunda pdgina de Pcmani'a, o via e-mail a rendermania.pcmania@hobbypress.es 



Babel Virtual 

Hoy nuestro foro es un verdadero Babel en cuanto a las tecnicas y 
programas empleados por los autores. 3D Studio, Imagine, POV, Moray e 
incluso MAX han sido utilizados para crear los trabajos que podeis 
admirar hoy. Extraterrestres, soldados espaciales, maquinas medievales, 
Mechs... Las herramientas, los temas, las preferencias y las ideas son 
diferentes en cada caso pero hay algo que todos los rendermaniacos 
tienen en comun: la pasion por la infografia. 




A Jose Antoniu Simieki Rajo y a su hijo Da- 
vid les gusto la original idea de Jorge Martin 
Cuervo, el cual publico en el numero 6 de Ren- 
dermanla una librerfa virtual de piezas del juego 
Tente. Por ello, Jose Antonio y David han reto- 
mado la idea y han creado una librerfa de piezas 

del juego K'nex. Las piezas, creadas con 3D Studio por Jose Antonio, fueron empleadas por David (de 12 anos) para montar el helic6p- 
tero de juguete que padre e hijo nos han enviado como ejemplo. Aqui se me ocurre una pequena idea: alguien podrfa disenar un juego de 
construction partiendo de cero y enviar modelos construidos con el. <,Quien sabe? Quiza, si la idea esta bien pensada, su autor podrfa re- 
gistrarla. Y aquf, si la idea atrae a un numero lo suficientemente alto de lectores, podriamos dedicar una portada al tema "Juegos de Cons- 
truction". Os felicito por vuestro trabajo. 
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Roberto Celorrio del Pino nos envfa un modelo basado en los marines es- 
paciales del capftulo de los angeles Sangrientos, del juego Warhammer 
40000. Este fantastico modelo esta, como podeis ver por las 
fotos, totalmente articulado, y Roberto nos adjunta 
no solo la malla correspondiente, sino tambien las 
texturas. En su carta, Roberto hace una autocritica 
bastante dura, ya que el modelo no es exactamente igual a la 
miniatura en que esta basado, pero en mi opinion el iinico defecto re- 
senable esta -como tambien senala el propio autor- en la hombrera, ya 
que esta secciona el antebrazo. El modelo ha sido creado con 3D Studio ha- 
ciendo uso del comando Fit y aplicando operaciones Csg y de deformation. 
Roberto ha declarado su modelo como de libre uso y tan solo pide que se 
mencione su nombre. ;Enhorabuena por tu magm'fico trabajo! Espero ver lu- 
char algun dfa a tu infante en algiin ;Waaagh! o en alguna invasion Geneleaster. 








An«el Ruiz Guijarro 

nos ha enviado su 
primer trabajo con 
Imagine. Se trata de 
un modelo femenino 
creado para hacer 
compafiia a Ray y 
defenderle de los 
abusos del grandu- 
llon que aparecio en 
el niimero 5 de Ren- 
dermam'a. Pues bien. 
amigo Angel, siento 
desilusionarte, pero 
Ray ya esta enamo- 
rado desde hace 
tiempo. Su corazon 
virtual suspira por los 
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Ha, sin embargo, le ha dado ca 
endo que no es mas que un mu 
En cuanto a lo que dices sc 
mplear la edition de puntos, e 
e Formas o una mezcla de tec 
jas para el infografista. Cada 
is herramientas que prefiere. 
otar que unos pechos "mas rez 
luneco (yo se los quitan'a y le 
ohetes). En cuanto al traspas 
nagine a POV, el iinico conver 
t los ficheros .obj es 3dto3d c 
lcluye en este niimero. Ah, en 
l modelo, yo prefiero casi sieir 


huesos de una de las 
chicas de Tomwoof. 
labazas hasta ahora adu- 
rieco de madera. En fin.... 
bre los pechos, podri'as 
magnetismo o el Editor 
nicas. No existen reglas 
uno modela empleando 
De todas formas te hago 
les" desentonarian en tu 
pondria mejor un lanza- 
o de los modelos desde 
sor que conozco que tra- 
e Thomas Baier. que se 
cuanto a lo de trastear en 
pre empezar desde cero. 




Benjamin Alhares Moreno regresa 
a estas paginas para enviar algunas 
imagenes que representan un gran 
avance con respecto a sus anteriores 
trabajos. Benyi nos e.;via una extensa 
carta en la que comenta el proceso de 
desarrollo de sus escenas y en la que 
pide unos comentarios. Pues bien. 
tus escenas me han parecido magnfficas pero... ^por que tie- 
nen tan poco color? El efecto general es un poco fri'o. Quiza 
habria sido conveniente dar un color distinto a la cabeza del 
primer piano de Futuras, para que resaltara mas sobre el fon- 
do, o bien cambiar el color de este. Por otro lado, estoy de 
acuerdo contigo en el papel que juegan las texturas metalicas 
en las robots, y me ha impresionado el estudio que has hecho 
para el Escorpion y el modelo en si, aunque creo que hubiera 
quedado mejor como escorpion que como nave espacial. 
iHubiera dado mucho mas asco! Tambien habrias debido po- 
ner un fondo menos pobre en la escena del escorpion (a fin de 
cuentas echaste mucho esfuerzo en el modelo, <,Por que no 
entonces algo mas de trabajo para presentarlo?). En fin, como 
modelador has mejorado un monton y estoy deseando ver 
acabada a la chica que estas preparando con Metaballs. 
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Alberto Riera Sanchez nos ha enviado las que quiza seran sus ultimas imagenes 
con 3D Studio, ya que piensa pasarse a MAX. Debido a un desastre en su disco du- 
ro, Alberto no ha enviado todos los ficheros de generacion pero su carta (que debe- 
ria haber enviado tambien como fichero) me ha convencido de la autoria de las ima- 
genes. Alberto me ha pedido una pequena crftica asf que ahf va: tu punto fuerte 

parece ser la 

ambientacion de las escenas mas que el modelado en si (contraria- 
mente a como sucede con la mayorfa de los rendermanfacos). Pan- 
demonium2. por ejemplo. resulta asombrosamente tetrica, a pesar 
de la excesiva sencillez del templo (y de la textura que le has pues- 
to). Algo parecido ocurre con las demas escenas: en Alien, el mo- 
delo (hecho con metaballs) no parece demasiado resulton en si mis- 
mo. pero en el contexto de la imagen transmite una sensacion de 
peligro (por cierto, creo que acertaste al no ponerle ojos). Tambien 
me ha gustado la escena del Androide. En resumen: creo que si po- 
tencias la complejidad de tus modelos conseguiras unas escenas 
esplendidas. Todo lo demas: la composicion, las ideas, la atmosfe- 
ra, etc., me ha gustado bastante. 





Ming Lee Cluiei 

ha enviado una esce- 
na donde puede verse 
un modelo fiel del 
fantastico Marauder, 
cuyo diseno sirvio de 
base para el Mech 
que incluf como 
ejemplo en el numero 
7 de Rendermam'a. 
Tengo que confesar 
que tu Mech me pare- 
ce mucho mas atractivo que el mib. aunque espero superarme proximamente si se Mega 
a celebrar una batalla entre Mechs en alguna de las proximas portadas. 

Sin embargo, tengo que decir que uno de tus discos llego defectuoso. ^Contenia las 

mallas de este modelo? 
En ese caso espero que 
me las envies de nuevo 
junto con alguna nota 
indicando algo sobre el 
proceso de creacion. En 
cuanto a tu pregunta so- 
bre como enviarnos 
animaciones, supongo 
que lo ideal seria hacer- 
lo en un CD, ya que to- 
do el mundo tiene uno 
(yo por ejemplo no dis- 
pongo aun de ningiin 
removible). 




Carlos Vilas Arias ha decidido 
apoyar al bando humano con varias 
catapultas hechas con Moray y POV. 
En principio su plan consistfa en en- 
viar un mago-enano, pero al final se 
decidio por los lanza-pedruscos, de 
los cuales uno es mas bien un trans- 
porte de municion que una maquina 
de guerra. jGracias por tu apoyo. 
Carlos! Y la proxima vez no emple- 
es tanta niebla en la escena. 
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Roberto eh' los Ojos 
Gracia nos envia sus pri- 
meras escenas con POV. 
En su carta Roberto nos 
cuenta como ha pagado su 
condicion de Povnovato. 
La verdad es que me ref 
bastante con lo que men- 
cionas sobre las ventanas 
del rascacielos (Roberto 
as puso todas a mano y 
,olo despues se entero de 
a existencia de la senten- 
cia While). En fin, a mi me 
ha ocurrido algo parecido 
-si no peor- con mis mo- 
delos y 3dto3d. En cuanto 
a While, me parece que 
aiin no has acabado de pi- 
llarle el tranquillo a 
las sentencias de 
programacion, ya 
que dices que no su- 
piste utilizar esta 
sentencia con las 
ventanas de la esce- 
na de la residencia. 
Por otro lado tus 
imagenes me han pa- 
recido magm'ficas 
para ser las primeras 
y espero ver pronto 
las siguientes. 




Francisco 
Palao Reines 

es un nuevo 
aficionado a la 
infografi'a que 
nos envia sus 
primeros traba- 
jos con MAX. 

Se trata de dos nuevas maquinas de guerra dise- 
fiadas para participar en la batalla virtual. El pro- 
blema es que no se aiin nada de MAX y no pude. 
por tanto, editar los modelos para incorporarlos 
a la batalla (ademas, no conozco ningun traduc- 
tor para MAX). Sorry. En cuanto a la cn'tica so- 
licitada, creo que aun puede mejorar mucho en 
todo lo relativo al modelado aunque, como no 
conozco MAX, no puedo dar demasiados deta- 
lles utiles. Sorry otra vez. 





Tengo que agradecer a Victor Tovt'o Ciercoles el envfo de 3dto3d. Lo 

cierto es que hasta ahora me habia pasado inadvertida esta estupenda 

herramienta de conversion de formatos. En cuanto hice las primeras prue- 

bas con el lamente no haber 
tenido antes este programa. 
jLa de trabajo inutil que me 
hubiera ahorrado solo en este 

numeral Victor nos envia hoy sus primeros trabajos: un par de escenas y una anima- 
tion de un Mech modelado con Imagine y exportado a POV. Victor ha incluido en su 
carta una description completa del proceso de traduction del modelo a POV (lo cual 
fue lo primero que llamo mi atencion). Tanto las escenas como la animation se han 
renderizado desde POV y Victor solicita otra de esas 'Wticas constructivas" que ha- 
cen que tanta gente no duerma bien por las noches. Pues bien. basicamente lo que 
puedo decirte es que aiin puedes mejorar mucho en el apartado de modelado. Dedica 
por ahora mas tiempo a esto antes que a otras cosas como la ambientacidn o la ani- 
macion. Gracias de nuevo por el 3dto3d. Espero tus proximos trabajos. 
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